Add yq to the kitchen sink and per-language Docker images - #756

@iwahbe I've added yq to the language-based containers as well - is that ok or should it remain in the "kitchen sink" image only?

Why do we need this in the per language containers? From the description this only really seems useful for yaml, so there shouldn't be any need to add it to language containers as well?

Customer requesting this (and I guess others) are running YAML programs but have pre-run scripts that are in python and since the language containers are a little smaller, this suits their purpose.

Personally I don't think this is right still. The language containers are intentionally small, with only the tools for the language installed. I don't think we should bloat them because some people use them for purposes they are not designed for, that's exactly what the kitchen sink container is supposed to be 🤔

Yeah, I agree with @tgummerer here. I can see it in kitchen sink and in the yaml image.

If we add yq everywhere, should we also add jq? What else? I prefer being strict here.

You can always extend an existing image.

Note: The .ubi variants and base images were intentionally left untouched, as UBI9/microdnf repositories don't carry a yq package like Debian Trixie does.

Ideally (not a blocker imo) we'd also add it to the UBI yaml image (I don't think there's an UBI kitchen sink).